Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d12 / mflms101.arc / MFLMS.DOC < prev next >

Wrap

Text File | 1989-11-25 | 44.3 KB | 1,268 lines

============================== = MICROFIRM FUNCTION LIBRARY = = for Microsoft C & Quick C = = - by - = = Bob Stout = ============================== Functions and Documentation Copyright 1988-89 by Robert B. Stout dba MicroFirm Portions Copyright 1986-87 by Steven E. Margison -- All Rights Reserved -- --------- TABLE OF CONTENTS --------- Introduction ................................. 1 The Documentation ............................ 1 Installation ................................. 2 Linking ...................................... 3 Real Time Interrupt Handler .................. 4 Video Functions .............................. 5 A. Introduction .......................... 5 B. Initialization ........................ 5 C. De-Initialization ..................... 6 D. Cursor and Character Placement ........ 6 E. Writing Characters and Attributes ..... 7 F. Miscellaneous Operations .............. 7 G. Video Page Switching .................. 8 H. Reading from Video Memory ............. 9 Utilities .................................... 10 Rebuilding Libraries.......................... 13 "We Get Letters" ............................. 14 Shareware & Online Help ...................... 17 Warranty ..................................... 20 Registration Form ............................ -- MicroFirm Function Library for Microsoft C & Quick C I. INTRODUCTION The heart of the C language is its library. Each compiler has its own library of functions, which is complete only to the degree that the compiler author wishes to make it. The Microsoft C compilers are excellent products, and come with a very extensive function libraries which have all the usual "standard" functions, plus many DOS functions as well. However, the more functions a programmer has at his disposal, the shorter the time from idea to complete program. That's where The Microfirm Function Library comes in. With over 200 functions it greatly enhances program development with Microsoft C & Quick C. The MicroFirm Function Library has an entire set of direct video functions originally written for the Turbo C compiler, and modeled after similar functions supplied with the Zortech and earlier Datalight C compilers. Even though many compiler vendors now offer direct video access packages, the MicroFirm Function Library's is an attractive alternative. II. THE DOCUMENTATION The documentation for the library is contained in the file, MFL_FUNC.MAN, which describes each function. A companion quick reference, MFL_QREF.DOC, is also provided which briefly lists the prototypes and functional descriptions for all lirary functions. Additional documentation includes TKNOTES.DOC, containing technical notes on the 1.01 release, README which contains miscellaneous information along with changes from previous versions, and CREDITS wherein the folks who helped make this library a reality are given proper recognition. MicroFirm Function Library for Microsoft C & Quick C Page 1 III. INSTALLATION The MicroFirm Function Library is distributed as five library files for each type of memory model. (Only the full registration with source has all five libraries. The filenames are: MFLMSS.LIB Small Memory Model MFLMSC.LIB Compact Memory Model MFLMSM.LIB Medium Memory Model MFLMSH.LIB Huge Memory Model MFLMSL.LIB Large Memory Model For the remainder of this manual the libraries will be referred to as MFLMSx.LIB. A typical hard disk installation of Microsoft C or Quick C will consist of several directories, one of which will contain all the "include" files (those with ".H" extensions) and one with the library files (those with ".LIB" extensions). All files in The MicroFirm Function Library" with an ".H" extension should be placed in the directory with the other ".H" files. Similarly, all MicroFirm Function Library files with a ".LIB" extension should be placed with the other ".LIB" files. The documentation and source files from The MicroFirm Function Library" do not need to be on the hard disk, as they will only be used to print the documentation or modify the function source. They are not used in the creation of a program. The executable utilities (*.EXE) files supplied with The MicroFirm Function Library may be optionally placed in any directory specified in your PATH environment. These programs are all examples of function usage and C programming, and do not directly relate to program development. However, they are useful and should be placed on your system for access. The files in The MicroFirm Function Library with an extension of ".BAT", ".MFL" or ".MAC" are required only for re-assembling the assembly language modules from this library. They do not need to be placed on your hard disk unless you plan to re-assemble any ".ASM" source code files. MicroFirm Function Library for Microsoft C & Quick C Page 2 IV. LINKING The MFLMSx.LIB library must be linked with any other libraries whenever a function is used in your program. Some programs may not use MFLMSx.LIB functions, and therefore the linking of the library may be eliminated to save time. In addition, if you have other third party libraries, be sure to include them after MFLMSx.LIB. There are several methods to invoke the MFLMSx.LIBs when linking under Microsoft C or Quick C. Refer to your compiler manual or on-line help for information on using the libraries either from the command line (using CL.EXE or QCL.EXE) or within the QC programming environment. MS LINK.EXE can link files with case-sensitivity on or off. With case off, the symbols foobar() and FOOBAR() would be considered the same. With case on, they would be different. C is inherently a case sensitive language so, though it is really bad form to name functions or variables with identical names but varying case, The MicroFirm Function Libraries are all compiled and/or assembled with case-sensitivity enabled. MicroFirm Function Library for Microsoft C & Quick C Page 3 V. REAL TIME INTERRUPT HANDLER A special feature of The MicroFirm Function Library is the "ticker" interrupt handler function. This function provides the programmer with the ability to install a special routine to intercept DOS interrupt 1CH. ticker() is a pre-built handler which allows the user to perform operations relative to the system's clock. A special variable may be loaded with a value and then tested at intervals. When the variable has hit zero, a specific amount of time has passed. The variable counts 18.2 times per second, and is installed on INT 1CH. The usage of this interrupt handler forces some hard rules on the programmer. Since this is an interrupt routine which is called asynchronously to your program, it ABSOLUTELY MUST be un-installed BEFORE your program exits to DOS. To do otherwise will invariably cause the next program run to crash the system, since the 1CH interrupt will then be invoked to a section of code in the new program which is NOT intended to be run from int 1CH. Therefore, it is imperative to control exits from your program when using the ticker. This means that your program should exit from only one place, which calls removetick() before performing the actual exit. With good program design, this is easy to accomplish. (Watch out for my error(), cant(), badext(), and eraok() functions, though, since they will exit the program all by themselves!) What isn't so obvious is the manner in which a program may exit beyond control of the program itself. This is done if the user types a control-break, or responds with (A)bort to a DOS critical error. To avoid exiting the program under these circumstances, any program which uses the ticker MUST ALSO use Turbo-C's ctrlbrk() AND harderr() functions to trap and cleanly process a program exit. The Turbo-C function "atexit()" can also be used to insure that the ticker is removed upon ANY program exit, and is probably the preferred means of accomplishing this. The function removetick() would be registered with atexit() in order to insure it is called upon exit. One exception: if the program is a terminate and stay resident (TSR) utility which needs interrupt 1CH to function, then removetick() should NOT be invoked before using the resident exit DOS command. The ticker interrupt routine resolves time only to about 55 milliseconds. For timings with finer resolutions, the 8253 timer chip may be utilized for timings to microsecond resolution. Refer to the documentation on the high resolution timer function, uclock(). MicroFirm Function Library for Microsoft C & Quick C Page 4 VI. VIDEO FUNCTIONS A. Introduction The MicroFirm Function Library provides a complete facility for direct writes and reads in video memory. Direct video memory, dvid for short, provides the programmer with a means of creating extremely fast screen displays, with full control over colors and attributes. Virtually all good programs, commercial or otherwise, make use of direct video access to create the rapid, sparkling displays that attract users. There is one gotcha, though. Direct video access works only on systems which are truly IBM compatible. Thankfully, this is almost every PC-type system nowadays. However, there still may be the occasional wierdo system which places video memory at an oddball address. With these systems, the direct video access package in this library will fail. However, since there is a BIOS override, it should still be possible to configure a program to operate using rom-bios services for those cases. Using dvid is very simple, but carries some extra responsibility for the programmer, especially if the program being created is intended for public distribution. Some things to consider are: * provision for forcing black & white on a CGA, in case the user has only a monochrome monitor * provision for changing the default colors. (Just because YOU like magenta text on a blue background doesn't mean that everybody else does!) * provision for forcing bios routines in case the user has an oddball video system. * sensing a monochrome adapter card (MDA) and altering the program accordingly; i.e., no video page switching, and an underline attribute. Of course, you can always specify that your program requires a CGA only, or an MDA only, but it is better to have the ability to work with both if possible. For the remainder of this discussion it may be handy to have a printout of DUMP.C (one of the supplied utilities) for reference. This program does not take into consideration user configuration, since it is supplied in source form. Don't like the colors? Edit the source and re-compile it! As a matter of fact, this program serves as a good "test bed" for the dvid functions. Many modifications are possible to demonstrate the use of the dvid functions. B. Initialization Before the dvid functions can be used, the dvid_init() function must be invoked. This function investigates the system's resources and sets the base video address, number of rows, and columns, into its private memory area. This information is critical to proper dvid operation. Using any of the functions before invoking dvid_init() will probably cause problems on MONO boards, and definitely cause trouble with CGA or EGA boards. If the initialization procedure encounters any MicroFirm Function Library for Microsoft C & Quick C Page 5 type of video information which it cannot understand, then a flag is set and all video access through the system will then be done through rom-bios video services, instead of directly to memory. Generally, the only effect of this will be to make screen writing noticably slower, but still not as slow as normal text writing through DOS. In addition, it will NOT be possible to display one CGA video page and write to a different one. However, the occasions when this would occur should be very rare. There are ways to insure that EGA cards will behave as MONO or CGA cards. By using the vmode() function you can set the video mode desired before calling dvid_init(). Then, dvid_init() should obtain the correct mode from an EGA emulating a CGA, and avoid setting the bios flag. dvid_init() has no effect if called more than once, since a check is made on an initialization flag. Therefore, it is not possible to change video modes and then recall dvid_init(). In order for dvid_init() to re-initialize the video system, dvid_done() must first be called to "de-initialize" the video system and restore all internal defaults. C. De-Initialization There is really no overwhelming need to call the dvid_done() function, unless you just happen to be a "neat-nik". dvid_done() updates the screen cursor position and restores the cursor shape to what it was when dvid_init() was invoked. In addition, it will restore all of the dvid function internal parameters to their default values and make possible the recall of dvid_init(). Normally, dvid_done() would be called just prior to exiting the program. D. Cursor and Character Placement The dvid system maintains two sets of row/column parameters. The first indicates where the NEXT character will be written in the video memory. The second stores the position of the REAL onscreen cursor. Since rom-bios routines are used to change the location of the onscreen cursor, it is not efficient to continually update the onscreen cursor for all dvid write operations. The dvid_flush() function is provided to perform that operation. I will refer to the "internal" cursor, and the "screen" cursor in the following discussions. The internal cursor is the position which will be next written. The screen cursor is the actual onscreen cursor, whether it is actually visible or not. All of the dvid functions which take a row/col value and a character or string argument, such as dvid_say() or dvid_char_at(), will call dvid_flush() at the end of the operation to update the screen cursor to the internal cursor position. However, the lower level functions such as dvid_putchr() will NOT automatically update the screen cursor to the internal cursor. Normally, dvid_flush() is only called after a block of text is written and it is necessary for MicroFirm Function Library for Microsoft C & Quick C Page 6 cosmetic reasons to show where the cursor "really" is. Since it uses rom-bios functions, using dvid_flush() sparingly will increase overall screen display speed. The function dvid_move() is used to set the internal cursor position to a new location. Note that the screen cursor is NOT affected by a call to dvid_move(). E. Writing Characters and Attributes When writing with normal DOS functions to the standard output channel, no concern is ever made about screen attributes or colors. However, when writing directly to video memory, it is actually necessary to write out two bytes for each character; one is the character, the second is the attribute. The dvid system saves an attribute internally which is automatically written each time a character is written to video memory. At initialization, the attribute defaults to normal white on black. The dvid_attrib() function is used to change the default attribute to any valid attribute for the video mode in use. Refer to the file screen.h for a mnemonic list of screen colors and attributes. The primary function for placing characters to the screen is dvid_putchr(), although in practice dvid_say() and dvid_char_at() may actually be more useful. dvid_putchr() will properly place all 256 possible character values with these exceptions: 07H Sounds Bell 08H Backspaces unless internal cursor is in column 0 09H moves internal cursor right to next mod-8 column (horizontal TAB) 0AH moves internal cursor down 1 row (linefeed) If internal cursor is already at bottom of screen, screen scrolls up by 1 line 0DH moves internal cursor to column 0 of current line (carriage return) 0BH moves internal cursor up one line, unless cursor is already on line 0 (vertical TAB) 7FH (delete) is ignored All other characters below 20H (space) are ignored A new feature of version 1.50 allows all control characters to be displayed directly. The dvid_raw() function controls handling of these special characters. Called with a TRUE argument, all dvid functions will display control characters literally. Called with a FALSE argument restores the operation listed above. F. Miscellaneous Operations There are a number of other functions to aid in screen management. As noted above, a screen attribute can be set and altered at will. The function dvid_getattr() will return the value of the current attribute in use, and the current video MicroFirm Function Library for Microsoft C & Quick C Page 7 page selected for writing. In order to erase characters, dvid_e2eol() is provided to erase from cursor to end of line, and dvid_e2eos() erases from cursor to end of screen. In each case, the cursor position used is the internal cursor, and the screen cursor is updated automatically to match. To clear the entire screen, do: dvid_move(0,0); /* cursor to upper left corner */ dvid_e2eos(); /* erase from 0,0 to end of screen */ - or - dvid_cls(); /* performs a direct screen clear & home cursor */ The CGA video card must be written to (or read from) only at certain times to prevent video "snow". Monochrome cards do not have this problem. Normally, all dvid functions will automatically synchronize with the CGA card to suppress snow. However, it is possible to turn synchronization on and off with the dvid_sync() function. An argument of 0 (FALSE) will turn sync off, and a non-zero argument (TRUE) will turn sync on (default condition). Why turn sync off? Well, some EGA cards do not produce snow, so that sync is not needed when they are used in CGA mode. Or, in some cases, the extra speed of writing without sync may be preferable to a little video snow. The function is provided so that full flexibility is possible. dvid_scroll() is a function which uses rom-bios features to scroll a region of the current screen up or down. Refer to the detailed description for this function for an explanation of its arguments. If dvid_init() cannot properly initialize itself, it sets an internal flag which then forces the dvid functions to use only rom-bios video functions. This slows down video access, but provides compatibility for oddball video cards. As a backup to this, the dvid_bios() function can be called AFTER dvid_init() to force the use of bios. Note that once selected, there is no way to turn bios off without calling dvid_done() and re-initializing the entire video system. It is possible to change the attributes on a section of the screen by using the dvid_chgattrib(). Parameters are the starting row and column, the ending row and column, and new attribute. If using a CGA card, synchronization will be performed unless it has been turned off with dvid_sync(FALSE). Note that rom-bios functions will NOT be used with this function. Therefore, this function MAY fail if used on a card which does not map video into the "normal" areas, even though the use-bios flag has been set. G. Video Page Switching dvid_setpage() may be used to control the video page in use, if a CGA card is being used. (MDA card video paging is not supported.) If a CGA card is used in 80 column mode, there are 4 video pages in memory, numbered 0-3. For 40 column mode, there are 8 pages, 0-7. dvid_setpage() takes two arguments. The first MicroFirm Function Library for Microsoft C & Quick C Page 8 is the video page to select for all write/read operations. The second argument is FALSE to select the video page for write/read only, and TRUE to also select for display. Using this function judiciously it is possible to write to a video page not currently being displayed, and then switch to that page instantly. This can be done as follows: dvid_setpage(0, TRUE); /* select page 0 for write and display */ dvid_setpage(1, FALSE); /* select page 1 for writing, but do not change currently displayed page */ dvid_say(10, 5, "Hello World"); /* write to page 1 */ dvid_setpage(1, TRUE); /* make page 1 display now */ One caution is necessary when switching video pages. It is HIGHLY recommended that you insure a full return to page 0 before exiting the program. Leaving the system on a different page often prevents subsequent programs from working properly. H. Reading from Video Memory Although few programs will ever need to read what is on the screen, there is support in The Microfirm Function Library to accomplish this. The dvid_getchr() function will read the character and video attribute at a specified row/column position. Synchronization will be active or inactive as for writing, and the page selected for writing will be the page used for reading. MicroFirm Function Library for Microsoft C & Quick C Page 9 VII. THE UTILITIES The MicroFirm Function Library comes with several utilities, including the C source code. Nothing earth shaking here, just some convenient programs to make life a little easier. All the programs use functions from The MicroFirm Function Library, and can serve as an example of proper usage. Here is a short description of each utility: INPATH This utility searches for an EXECUTABLE program in the current path. Typing INPATH at the DOS prompt will display the version number and a short usage message. To use, type: inpath <filename> where filename is the basename portion of the executable file to find. Note that an extension can be specified, but it is ignored. INPATH will first look for the file in the current directory, and then look in the PATH environment variable (if it is present) in the order specified. For each directory, INPATH first tries to locate a .COM file, then a .EXE file, then a .BAT file, since that is the order in which DOS searches for files. On the first match, INPATH reports the directory and full filename of the program and then exits. If none are found, that fact is reported. TEXTCOMP This is a quick Text Compare program to compare two ASCII files. Typing TEXTCOMP at the DOS prompt will display the version number and a short usage message. To use, type: textcomp file1 file2 where file1 and file2 are the two files to compare. If the files are identical, no more messages will appear. Otherwise, the program will report any lines which are different with the filename, line number, and a printout of the actual line. If one file ends before the other, the program reports which file terminated first. MicroFirm Function Library for Microsoft C & Quick C Page 10 WC WC counts words, lines, characters, and checksums one or more files. Typing WC at the DOS prompt will display the version number and a short usage message. To use, type: wc filename [-wcls] where filename is the name of the file to act upon. With no options, the program will report words, characters, lines, and a checksum, which is a simple binary addition of all character values. No, it ain't a CRC, but it is a quick check to see if it the same as another file under the same name. The options [wcls] tell the program to report ONLY the items specified: -w report only words -l report only lines -c report only characters -s report only checksum Note that giving all options is the same as giving no options. Since words, lines, and characters are meaningless in a non-text file, the program examines the filename extension to determine if the file is a binary or text file. This isn't a perfect method, but it is good enough. If the file extension is .COM, .EXE, .OBJ, .REL, .PFS, .LIB, or .BIN, then only the checksum is reported, overriding all other options. The program supports wildcards in the filename, as well as drives and directories. GTOD This utility will report the current system time and date in a variety of formats. GTOD may be invoked with or without options. Options may be preceded by dash, fraction bar, or nothing at all. gtod <options> -d report only date -t report only time -e report date in European format (DD/MM/YY) -s report seconds, if time reporting enabled -r reverse reporting order, with time first and date second -l spell out month in long format -n if option -l, then add name of weekday -m report time in 24 hour (military) format -v report version number -? usage message and exit no options defaults to -dt Output may be redirected to a file or another device, except for MicroFirm Function Library for Microsoft C & Quick C Page 11 error messages. GTOD demonstrates the system clock interface, as well as error(), monthis(), wkdayname(), i_dstr(), and weekday(). Program idea: allow calculation for other time zones. DUMP This program will dump any file to the screen in a "debugging" display format, in color if it senses a CGA card installed, or with blinks and highlights if a mono card is sensed. The direct video access functions are used. It will optionally highlight any selected byte whenever it is found, and it displays only 20 lines at a time and waits for a keypress to continue. Invoke the program as follows: dump filename -soffset -hbyte -r where filename is the file to dump, offset is the hex offset value in which to index into the file before dumping (defaults is 0000), and byte is the hex value to highlight (default is no highlight). The parameters may be in any order. The -r option is used to modify the "ascii" display in the rightmost columns. When not used, any non-printable ASCII character is displayed as a period. When used, all characters are displayed. DUMP demonstrates the use of getkey(), stuff(), error(), plus the direct video functions of this library, and the use of color attributes. MicroFirm Function Library for Microsoft C & Quick C Page 12 VIII. REBUILDING LIBRARIES If you want to remake the entire library from the source files, the procedure has been automated with a batch file and a make file. You will need, besides Microsoft C or Quick C of course, Microsoft's MASM, NMAKE, and LIB. The batch file to rebuild any library module or the entire library is BUILD.BAT and is self- prompting. To remake the libraries, you will most likely need to be on a hard disk. A dual floppy system can't handle it all in one chunk. If you have a floppy system, you will have to remake the library in pieces, bringing in only a few source files at a time. On a hard drive, make a subdirectory and copy into it all source and header files, plus the BUILD.BAT and MAKEFILE files from The MicroFirm Function Library's distribution disk. Then, making sure that CL.EXE or QCL.EXE, MASM.EXE, NMAKE.EXE, and LIB.EXE are in your current PATH, simply execute "BUILD.BAT LIBS m c" where "m" is the memory model and "c" is an optional switch ("Q") when used with Quick C. They will recompile and reassemble each source files and then create a new library file from the OBJ files. The rebuilt library file will be placed into the directory specified by the "LIB" environment variable. Afterwards, you may delete everything in the working directory. BUILD.BAT and MAKEFILE are only supplied with full source registration. To replace only selected functions in the library, as after a modification, use "BUILD xxx.OBJ m c" where "xxx" is the module name without its .C or .ASM extension and "m" and "c" are as described above. Be sure to update all five libraries. MicroFirm Function Library for Microsoft C & Quick C Page 13 X. SHAREWARE AND ONLINE HELP Shareware is "try-before-you-buy" software, reasonably priced and user-supported. This simply means that you can get trial copies of shareware from anyone who has a copy, or often from bulletin board systems. If you use and like the program, then the author asks that you register (purchase) the program for an amount usually much smaller than an equivalent commercial program. By registering you will often also receive notice of available upgrades or supplemental programs. Keep in mind that the purchase of a program from a public domain distributor or payment to an online service (such as CompuServe) does NOT constitute registration of the program since the producer of the program does NOT receive one penny of that payment. Shareware is NOT public domain software, and continued use of a program carries with it the OBLIGATION to purchase the program. The free distribution method is intended only as a means of obtaining a copy to evaluate before purchasing. The MicroFirm Function Library is a shareware program. If you use it, please complete the order form enclosed with the distribution. You will be placed on a mailing list for any future upgrade notices, and will be registered as a user of this product. You will also receive a set of diskettes with the latest version, plus the H, C, M, and L model libraries, and all source code. Online help is available via BIX (bob.stout) to registered users ONLY. Help is also available by mail. I will try to answer all letters within 48 hours. Non-registered users must include a SASE for a reply. The degree of help offered to non-registered users is purely discretionary. No phone calls, please. (Users outside the U.S. cannot, of course, send a SASE. I will excuse you from this requirement.) The Small model library, documentation files, and utilities of The MicroFirm Function Library may be freely exchanged or given away. (This is all the files on Disk #1 of a distribution set.) However, they may not be included or "bundled" with any software which is sold or is a commercial product without prior permission. No charge may be made for copying or transferring the files, except that PC Users groups and PD/Shareware distributors (such as PC-SIG, or Nelson Ford's Public Software Library) may charge a nominal fee not to exceed $6.00 ($12.00 outside the U.S.). (Please request a complementary copy of the latest release rather than use a copy from another user. This insures that you have the most accurate copy, and that you will be on my list for future updates.) The MicroFirm Function Library and its documentation may not be transferred nor exchanged in any modified form. If you really want to "hack" the source or the documentation, by all means do so; but don't give the hacked version to anyone else. I cannot be expected to help others use this product if it is not the same as it was when distributed. Under no circumstances may the copyright notices be altered or removed from the product or this documentation. MicroFirm Function Library for Microsoft C & Quick C Page 17 If you decide not to use this product, then just erase it or pass it on to someone else. If you do use it, please honor your obligation and send in your registration. Inexpensive shareware cannot continue to exist if those who use it treat it as a gift, rather than as a product for which the author must receive payment. Shareware used regularly without payment is piracy just as much as illegally copying "Lotus" or any other commercial product. Ignore the claims by some people that shareware, because of its unique distribution method, carries no obligation to the regular user. These claims are false, and discourage many good programs from remaining as shareware. MicroFirm Function Library for Microsoft C & Quick C Page 18 XI. WARRANTY and CREDITS Oh, this shouldn't be necessary among friends and gentlemen, but it's really the lawyers who run the world and they say we gotta do this: ** The MicroFirm Function Library functions and all documentation are copyright 1988-89 by Robert B. Stout and/or copyright 1986, 1987 by Steven E. Margison. ** These functions and documentation are provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. ** The user of these functions and documentation agree to hold the author and/or distributor(s) of this material harmless for any direct or consequential damages resulting from its use. In other words, "you're on your own!" ** IBM is a registered trademark of International Business Machines Corporation. ** MS-DOS is a trademark of MicroSoft Corporation. ** Microsoft C and Quick C are registered trademarks of Microsoft, Inc. ** Zortech C and Zortech C++ are registered trademarks of Zortech, Inc. ** Turbo-C is a registered trademark of Borland International, Inc. ** Other registered trademarks may be used herein and are acknowledged. MicroFirm Function Library for Microsoft C & Quick C Page 19 ======================================================================= SOFTWARE REGISTRATION FORM AND ORDER ======================================================================= A separate form must be filled out for each product ordered or registered. This form may be photocopied, printed out, or edited to include all information and re-printed. PRODUCT: -------- MicroFirm Microsoft LIBRARY VERSION 1.01 ------------ QUANTITY: Amount: _____ Registration with Source code $25.00 ea $______ _____ Update from MFLZT or SMTC $10.00 ea $______ _____ Additional Zortech C version $10.00 ea $______ Shipping outside U.S. or Canada $ 3.00 $______ Surcharge for non-U.S. Funds $ 5.00 $______ TOTAL DUE $______ Source code is NOT SHAREWARE and is not to be transferred to other users. Only the DOC files, header files, utilities, and S library are released into shareware. Corporations: Write with your requirements for a quote on multiple copies or site licensing. If you already have this library, where was it obtained? [ ]BIX [ ]Friend [ ]Employer [ ]BBS:__________________ Version_____ Serial No._________ If updating from SMTC: Version_____ Serial No._________ Payment is by check[ ] or money order[ ] (Sorry - no COD or charges) NAME _______________________________________________________ COMPANY ____________________________________________________ ADDRESS ____________________________________________________ CITY _______________________________________________________ STATE___________________________ ZIP _______________________ ======================================================================= Send completed form and payment to: MicroFirm P.O. Box 428 Alief, TX 77411 ======================================================================= - do not write below this line - recd________ sent________ version_______ serial no.__________________